1. Field of the Invention
This is a continuation application of U.S. patent application Ser. No. 10/246,909, filed on Sep. 19, 2002 by Peter Daniel Birk, which is now issued as U.S. Pat. No. 7,448,066. This invention relates to, but is not limited to, the fields of application server security management systems and tools.
2. Background of the Art
Application servers are server programs executed by a computer or computing platform in a distributed network such as an intranet or the Internet, and which provide business logic for an application or service. Companies such as International Business Machines (“IBM”), Microsoft Corporation and Sun Microsystems provide software suites for developing, managing, deploying, and running application servers on a wide variety of hardware platforms including, but not limited to, personal computers, network servers, mainframes, and workstations, targeted for a wide variety of operating systems including, but not limited to, UNIX, Linux, IBM's AIX, OS/2, and OS/390, Microsoft's Windows, and Sun's Solaris. IBM provides a well-known and widely-used application server suite known as WebSphere™.
Application servers may be developed in high level languages (“HLLs”) such as “C”, portable languages such as Sun Microsystem's Java, and combinations thereof. Portions of application logic may be embodied in Enterprise Java Beans (“EJB”), dynamic link libraries (“DLL”), program objects, applets, and servelets, depending upon the design methodology(ies) and language(s) used to develop the application server program.
Application servers typically cooperate with client computers and processes, such as web browsers and remote terminals, to interface to a user in order to perform a needed function or service. Common protocols for interacting with client computers and processes include, but are not limited to, hyper text transfer protocol (“HTTP”), transmission control protocol/Internet protocol (“TCP/IP”), secure sockets layer (“SSL”), and file transfer protocol (“FTP”). Client processes for cooperation with an application server may include, but are not limited to, stand-alone (e.g. browser independent) client programs, hypertext markup language (“HTML”) resources, browser extensions and plug-ins, extensible markup language (“XML”) resources, graphics and multimedia objects (e.g. TIFF, GIF, JPEG, AVI, etc.), Java server pages (“JSP”), active server pages (“ASP), personal home pages (“PHP”), Java modules, and Java Beans.
Application servers may interact with other system resources such as file systems and databases to read, store, create and copy data, as well. These system resources may be directly managed by an application server, such as a local cache, or may be accessible through and manage by other servers.
Application servers also often cooperate with security authorization and authentication servers to determine whether a user is who the user claims to be, and whether the user has permission or privileges to perform the actions requested, access the resources or data needed, etc.
Protocols for communications between application servers and such authorization and authentication processes, as well as with other system resources, may include any of the protocols previously listed for client communications, and often include other protocols defined by proprietary specifications as well as “open” standards such as Java Version 2 Enterprise Edition (“J2EE”) interface and communications models and Common Object Broker Request Architecture (“CORBA”).
Several implementations of CORBA are available in the industry, including IBM's SOM an DSOM architectures, Netscape Corporation's Open Network Environment (“ONE”), Sun Microsystem's RMI, and Microsoft's COM and DCOM architectures. These architectures allow client application program objects to “discover” the existence of other program objects which may be useful or needed for completion of a task or service. An Object Request Broker (“ORB”) is a component of such an architecture to which clients can send requests for particular functions. The ORB then forwards these requests to appropriate servers of which the ORB is aware and which can handle the function needed by the client. The client and server(s) then interact to determine appropriate interfaces to use so that the client may use the program objects provided by the server.
Of particular use in the CORBA architecture is the definition of Interoperable Object References (“IOR”). IOR's provide object references which are independent of platform on which the objects reside, and which are independent of ORB implementation.
As these types of applications which distributed objects have become more and more complex, a number of application management systems have been brought to market. Application management includes control and monitoring of an application from its installation and configuration, through its useful lifecycle including collection of metrics and tuning to maximize efficiency and responsiveness. The model adopted by application management systems is often a manager-agent model. The application is responsible for providing certain information to the management system, responding to requests for information actions from an agent of the management system, and communicating with an management system agent. The management system agent typically executes on the same hardware platform as the application which is being managed.
The management system communicates to one or more agents which are themselves in touch with the applications being managed. The management system may communicate with its agents using a proprietary protocol, or may use an “open” protocol such as Simple Network Management Protocol (“SNMP”) or Java Management Extensions (“JMX”). Some example management systems available on the market are Tivoli's Management Environment and IBM's WebSphere administration application.
Turning to FIG. 3, one embodiment of such a management system is shown using JMX Management Beans, or MBeans. MBeans are objects which are accessible via the standard JMX interfaces, and which provide developers with abilities to expose application-specific management interfaces. The JMX MBeanServer (33) runs the Application Server MBean (34), which is responsible for exposing interfaces of the application server (31) to the management application (37). Likewise, the JMX MBean Server (33) also runs the Application MBean (35), which exposes the application-specific management interfaces for the application (32) to the management application (37). The MBeanServer (33) also provides any adapters (36) necessary to bridge one or more management systems to the application so that the administration facilities of the application managers can be used in conjunction with the application.
In current versions of the IBM WebSphere™ Application Server product, an administrative server is the central point of contact where all administrative requests are directed. Securing this administrative server only required configuring application servers as secure clients, but the applications servers did not have to be configured as secure servers. As no user objects are allowed on the administrative server, and no administrative objects were allowed on the application servers, this approach met the needs in the art for some time.
However, as applications have evolved to include administrative functions and to use administrative objects on the application server, object level security (instead of server level security) is needed but not supported by legacy architectures. In some systems, all application processes include administrative resources which need to be protected, even though user resources may or may not need to be protected. Under present security schemes which are server-level security schemes, administrative object security would be disabled if user object security is disabled. For user objects and resources which really do not need to be secure, this enforces a performance penalty unnecessarily and undesirably by requiring authentication and authorization processes to be applied to these user objects. If the system is configured to disable security which by default includes disabling administrative resource security, the system is unnecessarily and undesirably exposed to security breach via the administrative functions. Therefore, there is a need in the art for a system and method which allows for object-level security configuration for application servers which contain user objects and administrative objects.